Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

debug log changes #39

Merged
merged 2 commits into from
May 10, 2022
Merged

debug log changes #39

merged 2 commits into from
May 10, 2022

Conversation

zkxs
Copy link
Collaborator

@zkxs zkxs commented May 9, 2022

  • Adds the ability for mods to only build debug log strings if debug logging is enabled via new public API:
    • DebugFunc()
    • IsDebugEnabled()

Originally part of #38, but I've separated the two

@zkxs zkxs force-pushed the debug-log-changes branch from 22724e5 to b0b34b4 Compare May 9, 2022 14:42
ljoonal
ljoonal previously approved these changes May 9, 2022
Copy link
Member

@ljoonal ljoonal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The few things I pointed out aren't worth blocking this over though 👍

@@ -6,6 +6,8 @@ namespace NeosModLoader
// contains members that only the modloader or the mod itself are intended to access
public abstract class NeosMod : NeosModBase
{
public static bool IsDebugEnabled() => Logger.IsDebugEnabled();
public static void DebugFunc(Func<string> messageProducer) => Logger.DebugFuncExternal(messageProducer);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the DebugFunc could be generalized a bit more, allowing any return types instead of just strings? And perhaps DebugFuncExternal could skip the debugging if null is returned, allowing that to be used as a shorthand for just running debugging functions without needing for it to be logged?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see allowing object parameters, but I don't think dropping nulls is what people would want from a Debug log API. For example, if someone is trying to do a quick and dirty DebugFunc(() => someFrooxObject) and that object is null, I think they'd much rather have the null logged than silently dropped.

Comment on lines 18 to 32
internal static void DebugFuncInternal(Func<string> messageProducer)
{
if (IsDebugEnabled())
{
LogInternal(LogType.DEBUG, messageProducer());
}
}

internal static void DebugFuncExternal(Func<string> messageProducer)
{
if (IsDebugEnabled())
{
LogInternal(LogType.DEBUG, messageProducer(), SourceFromStackTrace());
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I very much dislike the code duplication of this, but then I guess it's kind of a necessary evil, as they could deviate more in the future, and passing bool arguments isn't good either.

Copy link
Collaborator Author

@zkxs zkxs May 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the methods are a bit ugly, I agree, but I can't think of a better way of dealing with it. The good news is this crusty API is internal so we can always refactor it later if we have any ideas.

@@ -23,7 +23,7 @@ internal static void DebugFuncInternal(Func<string> messageProducer)
}
}

internal static void DebugFuncExternal(Func<string> messageProducer)
internal static void DebugFuncExternal(Func<object> messageProducer)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably check if the output of messageProducer() is null and in that case also not log?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the output of messageProducer() is already being null-checked, and it logs the string "null"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then DebugFuncExternal's output will always be logged. I guess it's a sensible option, just thought it might be neat to allow it to be used with potentially no output.

@zkxs zkxs merged commit a82b9cd into master May 10, 2022
@zkxs zkxs deleted the debug-log-changes branch August 26, 2022 19:03
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants